-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log weather periodically via OpenWeatherAPI - proof of concept/WIP #1307
Log weather periodically via OpenWeatherAPI - proof of concept/WIP #1307
Conversation
@CloCkWeRX, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Br3nda, @maco and @tygriffin to be potential reviewers. |
Super annoying, I have no idea how likes_controller has changes on it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any idea why schema.db changed so much?
Btw I have and old fork of grow stuff with moisture , light, temp,and fertiliser readngs per planting (actually per sensor, which is associated with many plantings). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A new rake task costs $ on heroku. Will this be part of an existing worker?
# "name":"London", | ||
# "cod":200 | ||
# } | ||
class PlantingWeatherLog < ActiveRecord::Base |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be per garden? Or even per location? The basil and the tomatoes are next to each other so have the same weather afaik
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went for planting so you can answer things like "Why did my leeks grow better last year than this year? Oh, 27 days of 40 degree temperature in a row on last year's planting" more easily
IE its simpler to do SELECT AVG(temp) FROM planting_weather_log WHERE planting_id = ?
and only have data recorded for the duration of the planting; than it is to do
SELECT AVG(temp) FROM garden_weather_log JOIN gardens JOIN plantings WHERE garden_weather_log.created_at BETWEEN planting.start and planting.end GROUP BY planting_id
x lots.
Plantings also have a start and end date usually (planting.active); while a Garden is forever; and at least one per user; even if they never do anything with the site.
I suspect we'd run out of the free tier of API usage if we did that for everyone's gardens.
For dealing with plantings in the same garden/location/etc; we can probably cache the API requests at a city/geocoded location level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about a weather log for a timestamp+location, then a planting links to that? Then the weather for a member's 100+ plantings isn't duplicated.
Prior to merge, I'll go clean it up to be only relevant bits. |
Will pick this up again in a while |
#863
For simplicity, I've just left a default/hardcoded API key in so its easy to play with - that'll be gone by the final version
TODO: